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Abstract 


In  order  to  gain  a  better  understanding  of  the  approach  and  the  technology  requirements  to 
support  collaborative  engineering  activities,  the  Collaborative  Capability  Definition, 
Engineering  and  Management  (CapDEM)  Technology  Demonstration  Project  (TDP)  initiated 
an  effort  to  implement  a  Collaborative  Engineering  Environment  (CEE).  The  US  Naval  CEE 
served  as  an  early  reference  for  the  CapDEM  team.  The  Integrated  Engineering  Environment 
(IEE)  described  in  this  report  is  one  component  of  the  Naval  CEE.  This  IEE  provides  essential 
engineering  data  management  functions  as  well  as  functionalities  that  enhance  collaborative 
teamwork. 

This  implementation  effort  has  provided  first-hand  experience  to  the  CapDEM  team  in  the 
understanding  of  the  process  involved  in,  and  the  requirements  for,  building  an  effective  IEE.  The 
details  of  this  IEE  implementation  process,  and  the  basic  requirements  for  developing  an  effective 
IEE  are  described  in  this  report. 


Resume 


Afin  d’ avoir  une  meilleure  comprehension  des  exigences  en  matiere  de  methode  et  de 
technologie  pour  appuyer  les  activites  d’ingenierie  collaboratives,  le  personnel  du  Programme 
de  demonstration  de  technologies  (PDT)  -  Definition,  ingenierie  et  gestion  collaboratives  de 
capacites  (DIGCap)  a  amorce  une  initiative  pour  mettre  en  oeuvre  un  environnement 
d’ingenierie  collaboratif  (EIC).  Tot  dans  ce  processus,  le  US  Naval  Collaborative  Engineering 
Environment  a  servi  de  reference  a  l’equipe  du  DIGCap.  L’ environnement  d’ingenierie 
integre  (Eli)  decrit  dans  le  present  rapport  est  un  element  du  EIC  de  la  marine  americaine.  Cet 
Eli  offre  des  fonctions  de  gestion  de  donnees  techniques  cruciales  et  des  fonctionnalites  qui 
ameliorent  la  collaboration  lors  de  travaux  d’equipe. 

Grace  a  cette  initiative,  l’equipe  du  DIGCap  a  acquis  une  experience  directe  du  processus  pour 
elaborer  un  Eli  efficace  et  des  exigences  pour  y  parvenir.  Ce  rapport  comporte  les  details  de  ce 
processus  de  mise  en  application  d’un  Eli  et  les  exigences  de  base  pour  elaborer  un  Eli  efficace. 
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Executive  summary 


The  function  of  a  Collaborative  Engineering  Environment  (CEE)  is  to  provide  project 
stakeholders  with  an  effective  interface  by  which  to  access  information,  utilize  specialized 
applications  and  communicate  with  each  other.  Ultimately,  the  CEE  should  promote  holistic 
system  thinking,  i.e.,  enable  stakeholders  to  understand  how  they  relate  to  each  other  in  the 
project,  hence  improving  their  relationship  to  the  process  and  its  application  through  more 
effective  collaboration. 

In  order  to  gain  a  better  understanding  of  the  approach  and  the  technology  requirements  to 
support  collaborative  engineering  activities,  the  Collaborative  Capability  Definition, 
Engineering  and  Management  (CapDEM)  Technology  Demonstration  Project  (TDP)  initiated 
an  effort  to  implement  a  CEE.  The  US  Naval  Collaborative  Engineering  Environment 
(NCEE)  served  as  an  early  reference  to  the  CapDEM  team.  The  Integrated  Engineering 
Environment  (IEE)  described  in  this  report  is  one  component  of  the  NCEE.  This  IEE  provides 
essential  engineering  data  management  functions  as  well  as  a  flexible  collaborative 
environment  to  support  a  geographically  distributed  project  team. 

This  implementation  effort  has  provided  first-hand  experience  to  the  CapDEM  team  to 
understand  the  process  involved  in,  and  the  requirements  for,  building  an  effective  IEE.  The 
results  are  captured  in  Section  3  and  4,  respectively.  In  short,  the  implementation  process,  as 
derived  from  the  lessons  learned,  involves  the  following  steps: 

•  Identify  the  application  this  environment  will  support 

•  Describe  the  engineering  activities  and  engineering  products  to  be  generated 

•  Determine  team  composition  and  the  computing  environment  (tools  and 
network  connectivity) 

•  Define  workflow  and  dataflow  within  the  IEE 

•  Develop/  modify  /  fine-tune  the  plug-ins  that  link  tools  to  a  central  repository 

The  two  basic  requirements  that  contribute  to  an  effective  IEE  are: 

•  Integrated  engineering  data  management  and  efficient  data  exchange  that 
enable  team  members  to  focus  on  their  domain-specific  tasks  rather  than 
worrying  about  data  maintenance  such  as  back  ups,  configuration 
management,  and  data  integration. 

•  Effective  way  for  team  members  to  acquire  project  situation  awareness  that 
enables  them  to  work  independently  yet  maintaining  enough  awareness  of  the 
progress  in  the  project  to  maintain  self- synchronization. 


Two  future  activities  have  been  planned  to  utilize  the  existing  IEE.  First,  the  IEE  will  be  used 
to  provide  engineering  data  management  for  the  CapDEM  Concept  Development  and 
Experimentation  (CD&E)  exercise.  This  CD&E  exercise  will  employ  the  same  set  of  tools  to 
demonstrate  the  application  of  capability  engineering  concepts  to  support  CD&E. 
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Second,  the  IEE  will  be  used  to  develop  a  Synthetic  Environment  Development  Environment 
(SEDE).  The  purpose  of  the  SEDE  is  to  provide  a  facility  that  will  assist  the  different  types  of 
Synthetic  Environment  (SE)  users  i.e.  stakeholders  who  identify  the  problem  to  be  addressed, 
engineers  and  specialists  who  provide  engineering  solutions,  and  SE  implementers,  so  that  SE  can 
be  delivered  faster,  better  and  cheaper.  These  two  activities  will  be  carried  out  in  budget  year 
2005/06  under  the  CapDEM  TDP. 
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Sommaire 


L’environnement  d’ingenierie  collaborate  (EIC)  a  pour  but  d’offrir  aux  intervenants  d’un 
projet  une  interface  performante  pour  acceder  a  de  1’ information,  utiliser  des  applications 
specialises  et  communiquer  entre  eux.  En  bout  de  ligne,  l’EIC  devrait  promouvoir  une 
approche  systemique,  c’est-a-dire  permettre  a  ces  intervenants  de  comprendre  leurs 
interrelations  au  sein  du  projet,  ameliorant  ainsi  leurs  liens  avec  le  processus  et  son 
application  grace  a  une  collaboration  plus  efficace. 

Afin  d’ avoir  une  meilleure  comprehension  des  exigences  en  matiere  de  methode  et  de 
technologie  pour  appuyer  les  activites  d’ingenierie  collaboratives,  le  personnel  du  Programme 
de  demonstration  de  technologies  (PDT)  -  Definition,  ingenierie  et  gestion  collaboratives  de 
capacites  (DIGCap)  a  amorce  une  initiative  pour  mettre  en  oeuvre  un  EIC.  Tot  dans  ce 
processus,  le  US  Naval  Collaborative  Engineering  Environment  ([NCEE]  environnement 
d’ingenierie  collaboratif  de  la  marine  americaine)  a  servi  de  reference  a  T  equipe  du  DIGCap. 
L’environnement  d’ingenierie  integre  (Eli)  decrit  dans  le  present  rapport  est  un  element  du 
NCEE.  Cet  Eli  offre  des  fonctions  de  gestion  de  donnees  techniques  cruciales  et  un 
environnement  de  collaboration  flexible  pour  appuyer  une  equipe  geographiquement 
dispersee. 

Grace  a  cette  initiative,  l’equipe  du  DIGCap  a  acquis  une  experience  directe  du  processus 
pour  elaborer  un  Eli  efficace  et  des  exigences  pour  y  parvenir.  Les  resultats  se  trouvent  dans 
les  sections  3  et  4  respectivement.  En  gros,  le  processus  de  mise  en  oeuvre  qui  a  ete  deduit  des 
legons  apprises  comprend  les  etapes  suivantes  : 

•  identifier  V application  appuyee  par  l’environnement; 

•  decrire  les  activites  et  produits  d’ingenierie  qui  seront  elabores; 

•  determiner  la  composition  de  1’ equipe  et  1’  environnement  informatique  (outils 
et  connectivity  de  reseau); 

•  definir  le  deroulement  des  operations  et  le  flux  de  donnees  au  sein  de  l’EII; 

•  developper/modifier/mettre  au  point  les  utilitaires  qui  lient  les  outils  au  depot 
central. 

Les  deux  exigences  de  base  contribuant  a  l’efficacite  de  l’EII  sont  les  suivantes  : 

•  Une  gestion  integree  des  donnees  techniques  et  un  echange  efficace  des 
donnees  pour  permettre  aux  membres  de  V  equipe  de  se  concentrer  sur  les 
taches  propres  a  leur  domaine  au  lieu  de  se  soucier  de  la  maintenance  des 
donnees,  comme  les  copies  de  securite,  la  gestion  de  la  configuration  et 

T integration  des  donnees. 

•  Un  moyen  efficace  de  sensibiliser  les  membres  de  V  equipe  a  la  situation  du 
projet,  ce  qui  leur  permet  de  travailler  independamment,  tout  en  etant 
conscients  des  progres  du  projet  afin  de  conserver  une  autosynchronisation. 
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V 


Deux  activites  ont  ete  prevues  pour  utiliser  l’EII  actuel.  Premierement,  il  servira  a  la  gestion 
des  donnees  techniques  au  cours  d’un  exercice  d’ elaboration  et  d’ experimentation  de  concepts 
(EEC)  du  DIGCap.  On  utilisera  lors  de  cet  exercice  d’EEC  les  memes  outils  pour  demontrer 
l’application  des  concepts  d’ingenierie  des  capacites  en  appui  a  l’EEC. 

Deuxiemement,  on  utilisera  l’EII  pour  elaborer  un  environnement  de  developpement 
d’ environnement  synthetique.  Cet  environnement  a  pour  but  d’ aider  les  differents  utilisateurs 
d’ environnement  synthetique  (ES),  c.-a-d.  les  intervenants  qui  identifient  les  problemes  a  rectifier, 
les  ingenieurs  et  les  specialistes  qui  trouvent  des  solutions  ainsi  que  les  realisateurs  d’ES,  en  leur 
offrant  une  meilleure  prestation  d’ES  -  plus  rapide  et  economique.  Ces  deux  activites  se 
derouleront  au  cours  de  l’annee  fmanciere  2005-2006  sous  la  tutelle  du  PDT  DIGCap. 
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1.  Introduction 


A  Collaborative  Engineering  Environment  (CEE)  is  an  environment  that  makes  use  of  a 
mixture  of  communication  and  information  technologies  to  facilitate  distributed  teamwork  at 
multiple  geographically-distributed  locations.  The  function  of  such  an  environment  is  to 
provide  project  stakeholders  with  an  effective  interface  by  which  to  access  information,  utilize 
specialized  applications  and  communicate  with  each  other.  Ultimately,  the  CEE  is  intended  to 
promote  holistic  system  thinking,  i.e.,  enable  stakeholders  to  understand  how  they  relate  to 
each  other  in  the  project,  hence  improving  their  relationship  to  the  process  and  its  application 
through  more  effective  collaboration. 

In  order  to  gain  a  better  understanding  of  the  approach  and  the  technology  requirements  to 
support  collaborative  engineering  activities,  the  Collaborative  Capability  Definition, 
Engineering  and  Management  (CapDEM)  Technology  Demonstration  Project  (TDP)  initiated 
an  effort  to  implement  a  CEE.  The  US  Naval  Collaborative  Engineering  Environment 
(NCEE),  as  described  in  Section  2,  served  as  an  early  reference  to  the  CapDEM  team. 

The  Integrated  Engineering  Environment  (IEE)  described  in  this  report  is  one  component  of 
the  NCEE.  This  IEE  provides  essential  engineering  data  management  functions  as  well  as  a 
flexible  collaborative  environment  to  support  a  geographically  distributed  project  team.  The 
main  challenges  and  lessons  learned  are  documented  in  [1].  This  report  provides  futher 
technical  details  on  the  implementation. 

Implementing  an  IEE  is  more  than  just  linking  a  set  of  tools  together.  In  order  to  optimize  the 
functionality  and  performance,  it  requires  careful  planning  and  detail  discussions  with  team 
members  to  understand  the  project  objectives,  members’  roles  in  the  project  and  their  existing 
workflow  and  toolset  to  accomplish  their  tasks.  An  IEE  implementation  process  is 
documented  in  Section  3,  together  with  a  high  level  description  on  various  aspects  of  this 
implementation. 

Based  on  the  experience  gained  from  this  implementation,  the  implementation  team  identified 
two  basic  requirements  for  and  IEE  to  support  effective  distributed  teamwork:  1)  strong 
project  engineering  data  management,  and  2)  ability  to  promote  project  situation  awareness  to 
all  team  members.  These  two  requirements  are  described  in  Section  4.  The  IEE  functionalities 
that  contribute  to  these  two  requirements  are  also  listed  in  this  section. 

Section  5  concludes  this  report  by  reiterating  the  benefits  gained  by  this  implementation  and 
describes  future  activities  based  on  this  IEE. 
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2.  Background 


Being  closely  linked  to  The  Technical  Cooperative  Panel  (TTCP)  Joint  Systems  Analysis  (JSA) 
Technical  Panel  4  (TP4)  activities,  CapDEM  benefits  from  the  TTCP  members’  experience  in 
building  collaborative  environments.  Among  the  member  nations,  the  US  Navy  Chief  Engineering 
Office  (CHEng)  offered  their  existing  CEE,  referred  to  as  the  NCEE,  as  a  case  study  for  other 
nations.  Consequently,  CapDEM  decided  to  follow  the  NCEE  approach  to  implement  the 
CapDEM  IEE. 

2.1  The  NCEE 

The  NCEE,  as  shown  in  Figure  1,  consists  of  three  elements:  the  Decision  Support 
Environment  (DSE),  the  Integrated  Engineering  Environment  (IEE)  and  the  Interoperability 
Data  Management  and  Analysis  (IDMA)  Environment.  A  detailed  description  of  the  NCEE 
can  be  found  in  [2].  The  purpose  of  the  NCEE  is  to  provide  an  integrated  digital  environment 
that  enhances  the  cooperation  and  exchange  of  data,  information,  knowledge  among  Naval 
stakeholders  engaged  in  force  systems  integration  and  interoperability  activities,  and  enables 
the  integration  and  interoperability  of  systems  across  the  spectrum  of  the  Naval  acquisition 
process. 


Integrated 
Engineering  \ 
Environment  \ 
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Figure  1  US  Naval  Collaborative  Engineering  Environment 
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The  Naval  IEE  features  an  integrated  set  of  tools  that  supports  distributed  engineering  teams 
engaged  in  requirements  analysis,  functional  analysis,  system  synthesis  and  assessment  of  forces 
system  architectures.  A  centralized  repository  maintains  a  systems  database  structure  that  is 
common  to  all  platforms  and  systems  within  the  Naval  force.  Figure  2  shows  the  US  Naval  IEE 
concept,  the  related  toolset,  and  the  flow  of  engineering  process  within  the  IEE. 


Figure  2  US  Naval  IEE  and  the  associated  engineering  process 


Based  on  the  input  from  NCEE,  CapDEM  started  to  implement  its  IEE  in  late  2003.  Figure  3 
shows  the  current  configuration  of  this  environment.  The  two-way  arrows  between  the  tools 
and  the  project  repository  (Interchange  Server)  indicate  that  data  flows  between  the  project 
repository  and  tools  through  the  use  of  plug-ins.  This  IEE  resembles  that  of  the  NCEE  with  a 
similar  set  of  Commercial-Off-The-Shelf  (COTS)  products,  they  are:  DOORS,  CORE,  Rose 
and  Interchange.  Two  software  tools  have  been  added  to  this  basic  toolset.  OpNET  is  a 
specialized  network  analysis  tool,  and  Integrated  Performance  Modeling  Environment  (IPME) 
is  a  human  performance  analysis  tool. 

The  IEE  is  currently  implemented  on  the  Defence  Research  Establishment  Network 
(DRENet)  Joint  Simulation  Network  (JsimNet)  subnet,  and  users  of  the  DRENet  can  access 
this  environment  regardless  of  their  physical  location.  Currently  users  at  Defence  Research 
Development  Canada  (DRDC)  Ottawa  at  Shirley’s  Bay,  DRDC  Valcartier  (Quebec)  and  at 
Joint  Staff  Operational  Research  Team  (JSORT),  have  successfully  accessed  the  project 
repository  during  several  technical  trials. 
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■  Life  Cycle  Traceability 

■  Change  Agent  Notification 

■  System  Representation 

■  Configuration  Management 

■  Tools  Integration 
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Figure  3  Configuration  of  the  CapDEM  IEE 


2.2  Tools  in  the  IEE 

The  toolset  in  the  IEE  contains  the  products: 

•  DOORS 

•  CORE 

•  Rational  Rose  /  Rose  RT 

•  Interchange  SE 

•  OpNET 

•  IPME 

2.2.1  DOORS 

DOORS  is  a  popular  requirements  management  and  analysis  tool  developed  by  Telelogic  Inc. 
[3].  It  provides  the  utilities  needed  to  capture,  track  and  manage  user  requirements. 
Requirements  can  be  entered  directly  into  DOORS  using  its  familiar  word  processor  style 
interface. 

Once  the  requirements  are  captured  in  DOORS,  they  can  be  tracked  and  managed  throughout 
the  project  life  cycle  using  a  variety  of  features,  such  as  views,  links  and  traceability  analyses. 
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2.2.2  CORE 


CORE  is  a  functional  analysis  tool  developed  by  Vitech  Inc.  [4].  The  CORE  product  family 
provides  a  flexible  combination  of  modeling  and  simulation  tools  supporting  product  and 
process  engineering.  CORE'S  object-oriented  environment  delivers  the  same  functionality 
from  a  single  user  workstation  to  large,  distributed,  client-server  teams. 

COREsim  allows  execution  of  the  integrated  architecture  by  dynamically  inferring  the 
behavior  model  that  resides  in  the  system  design  repository.  Discrete-event  simulation 
logic  identifies  timing,  resource  utilization,  and  model  inconsistency  including: 

•  Timeline  Analysis  -  COREsim  timeline  analysis  identifies  the  sequential  and 
concurrent  events  that  occur  during  the  simulation  based  upon  data  triggers, 
resource  availability,  random  probabilities,  and  outcomes. 

•  Resource  Analysis  -  COREsim  resource  analysis  monitors  resource  availability 
to  identify  bottlenecks,  resource  contention,  and  queuing  effects  on  system 
performance. 

•  Consistency  Analysis  -  COREsim  may  be  used  interactively  to  identify  logical 
inconsistencies  as  the  behavioural  model  is  developed.  This  provides  the 
engineer  with  a  dynamic  modeling  constmction  kit  for  establishing  a  complete 
and  logically  consistent  model  of  system  behaviorl. 

2.2.3  Rational  Rose  /  Rose  RT 

Rational  Rose  family  of  products  is  a  set  of  popular  modeling  and  development  tools 
developed  by  IBM  Inc.  [5].  Data  Modeller  is  a  visual  modeling  tool  that  makes  it  possible  for 
database  designers,  analysts,  architects,  developers  and  anyone  else  on  your  development 
team  to  work  together,  capturing  and  sharing  business  requirements,  and  tracking  them  as 
they  change  throughout  the  process.  It  provides  the  realization  of  the  ER  methodology  using 
Unified  Modeling  Language  (UML)  notation  to  bring  database  designers  together  with  the 
software  development  team.  With  UML,  the  database  designer  can  capture  information  like 
constraints,  triggers  and  indexes  directly  on  the  diagram  rather  than  representing  them  with 
hidden  properties  behind  the  scenes.  Rational  Rose  Data  Modeller  gives  you  the  freedom  to 
transfer  between  object  and  data  models  and  take  advantage  of  basic  transformation  types 
such  as  many-to-many  relationships.  This  tool  provides  an  intuitive  way  to  visualize  the 
architecture  of  the  database  and  how  it  ties  into  the  application. 

2.2.4  Interchange  SE 

InterchangeSE  is  a  data  integration  environment  developed  by  Trident  Systems  Inc.  [6]. 
Interchange  SE  allows  the  user  to: 

•  Graphically  view  or  edit  any  information  in  the  repository 

•  Configuration  manage  the  data  across  all  domains  of  information 

•  Share  common  data  between  similar  applications 

•  Interrelate  data  between  applications  in  different  domains 
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Interchange  provides  a  common  entity-relationship  graphic  interface  so  that  anyone  with  the 
Interchange  client  on  his  or  her  desktop  can  graphically  view  and  edit  any  of  the  information 
in  the  repository.  This  allows  them  to  participate  in  distributed  design  reviews,  quickly  access 
and  analyze  information  to  make  decisions  or  make  simple  changes  or  additions  to  the  data 
without  having  to  know  how  to  use  the  different  tools  used  on  the  project  just  to  view  the 
information.  Having  a  common  interface  to  this  integrated  information  saves  on  training  and 
licensing  of  the  other  tools.  Interchange  is  not  meant  to  replace  the  engineering,  cost  and 
project  management  tools.  Only  selected  people  working  in  a  domain  would  have  to  license 
the  specialized  tools  and  get  detailed  training.  The  user  can  also  graphically  verify  data 
completeness  by  performing  complex  queries  or  drill-downs  that  place  interrelated 
information  from  multiple  domains  in  a  single  view.  Finally,  Interchange  can  provide 
automated  alerts  to  the  user  to  changes  to  objects  of  interest. 


2.2.5  OPNET 

OPNET  Technologies  Inc.  is  a  leading  provider  of  management  software  for  networks  and 
applications  [7].  OPNET ’s  solutions  address:  application  performance  troubleshooting; 
network  configuration  and  security  auditing;  network  capacity  and  resiliency  planning; 
application  deployment  planning;  systems  capacity  planning;  and  network  technology  R&D. 
OPNET  solutions  have  been  operationally  proven  in  thousands  of  customer  environments 
worldwide,  including  corporate  enterprises,  government  and  defense  agencies,  network 
service  providers,  and  network  R&D  organizations. 


2.2.6  IPME 

The  Integrated  Performance  Modeling  Environment  (IPME)  is  a  Unix-based  integrated 
environment  of  simulation  and  modeling  tools  for  answering  questions  about  systems  that  rely 
on  human  performance  to  succeed.  IPME  provides  [8]: 

•  A  realistic  representation  of  humans  in  complex  environments 

•  Interoperability  with  other  models  and  external  simulations 

•  Enhanced  usability  through  a  user  friendly  graphical  user  interface 

IPME  provides  a  full-featured  discrete  event  simulation  environment  built  on  the  Micro  Saint 
modeling  software.  Additionally,  it  provides  added  functionality  to  enhance  the  modeling  of 
the  human  component  of  the  system.  Finally,  it  has  a  number  of  features  that  make  it  easier  to 
integrate  IPME  models  with  other  simulations  on  a  real-time  basis  including  TCP/IP  sockets 
and  tools  for  developing  simulations  that  adhere  to  the  Higher  Level  Architecture  (HLA) 
simulation  protocols  that  are  becoming  standard  throughout  the  world. 


2.2.7  Linkage  to  M&S  /  T&E  Environment 

The  linkage  to  a  Modeling  and  Simulation  (M&S)  /  Testing  and  Evaluation  (T&E) 
environment  is  desirable  because  of  the  potential  benefits  of  using  M&S  to  support  trade 
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studies  and  concept  validation.  However,  due  to  the  complexity  of  linkage  to  a  synthetic 
environment  (SE),  the  CapDEM  team  decided  to  address  this  linkage  at  a  later  time. 

2.3  Considerations  Affecting  IEE  Implementation 

Although  the  tools  in  the  CapDEM  IEE  were  selected  based  on  NCEE  recommendations, 
there  were  other  considerations  that  contribute  to  the  complexity  of  the  implementation.  The 
influencing  factors  include: 

•  the  application  this  environment  supports 

•  the  engineering  activities  and  products  to  be  generated 

•  the  engineering  team  members  and  their  roles 

•  the  workflow  and  dataflow 

Section  3  describes  these  aspects  of  the  IEE  implementation  in  detail 
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3.  Implementing  the  CapDEM  [EE 


The  CapDEM  team  has  gained  valuable  hands-on  experience  from  this  implementation,  and 
through  the  lessons  learned,  the  team  derived  the  following  implementation  process: 

Step  1 .  Identify  the  applications  this  environment  will  support 
Step  2.  Describe  engineering  activities  and  products 

Step  3.  Determine  team  members’  roles  and  their  computing  environment  (tools  and 
network  connectivity) 

Step  4.  Define  workflow  and  dataflow  within  the  IEE 

Step  5.  Develop/  modify  /  fine-tune  the  plug-ins  that  link  tools  to  a  central  repository 

The  rest  of  this  section  describes  the  current  IEE  implementation  following  this 
process. 

3.1  The  Application 

Although  the  IEE  has  been  developed  to  support  a  generic  systems  engineering  process,  the 
CapDEM  team  believed  a  concrete  example  was  needed  to  guide  the  implementation.  The 
Joint  Information  and  Intelligence  Fusion  Capability  (JIIFC)  Project  [9],  one  of  the  CapDEM 
use  cases,  was  selected.  This  application  of  the  environment  provided  the  team  with  a  good 
understanding  of  its  requirements  and  the  engineering  team  composition  needed  for  successful 
implementation  of  the  process  within  it..  In  addition,  project  datasets  are  available  for 
dataflow  development  and  testing  purposes.  Figure  4  shows  the  systems  engineering  process 
as  applied  to  the  JIIFC  Project. 


requirements 


Figure  4  Systems  Engineering  Process 
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3.2  Engineering  Activities  Supported  by  IEE 

Engineering  activities  define  the  workflow  within  the  IEE.  The  activities  described  below  are 

derived  from  the  experience  gained  from  the  JIIFC  use  case,  as  well  as  from  common  systems 

engineering  practices. 

Develop  Operational  Needs  /  Deficiencies:  The  statement  of  operational  needs  /  deficiencies 
is  usually  developed  by  management  stakeholders  at  the  strategic  level.  The  deficiencies 
are  then  translated  into  high  level  operational  requirements  with  preliminary  key 
performance  parameters.  Although  this  activity  may  not  directly  involve  the  engineering 
team  at  the  project  level,  this  will  be  the  trigger  to  initiate  a  project,  and  the  operational 
requirements  document  will  be  crucial  in  defining  the  project’s  objectives. 

Develop  Originating  Requirements:  This  activity  identifies  the  mission  and  the  scope  of  the 
project.  It  relates  to  the  originating  requirements  to  the  operational  needs  within  a  set  of 
predefined  scenarios.  In  order  to  determine  the  customer  acceptance  of  the  system,  an 
objective  hierarchy  of  the  system  is  created.  An  external  systems  diagram  is  also 
produced  at  this  stage  to  identify  the  inputs  and  outputs  of  the  system. 

Perform  Enterprise  Change  Proposal  (ECP)  Functions:  This  activity  is  responsible  for  the 
approval  of  all  requirements  submitted  for  approval  at  each  layer  of  modeling. 

Define  Operational  Model:  This  activity  captures  the  operational  architecture  according  to 
the  selected  architecture  framework.  Since  the  operational  architecture  is  likely  to  be  a 
team  effort,  the  various  parts  of  the  models  must  be  integrated  to  provide  a  complete  and 
consistent  picture  of  the  operational  architecture. 

Define  System  Model:  This  activity  captures  the  systems  architecture  according  to  the 
selected  architecture  framework.  Since  the  systems  architecture  is  likely  to  be  a  team 
effort,  the  various  parts  of  the  models  must  be  integrated  to  provide  a  complete  and 
consistent  picture  of  the  systems  architecture.  In  addition,  several  options  on  systems 
design  may  be  proposed  and  evaluated  to  derive  the  optimal  solution.  This  will  require 
strong  traceability  between  proposed  designs  and  trade  studies  (analysis  results). 

Define  Human  Factor  Performances:  This  activity  models  the  human- systems  interface  at  a 
more  detailed  level  in  order  to  evaluate  the  performance  and  identify  requirements  related 
to  human  factors. 

Manage  Models:  This  activity  encompasses  many  house-keeping  functions  required  to  maintain 
the  central  repository. 

Define  Network  Performance:  This  activity  models  the  network  connectivity  at  a  more 
detailed  level  in  order  to  evaluate  the  performance  and  identify  requirements  related  to 
communications  network. 

3.3  Team  Members  and  their  Roles 

Like  the  engineering  activities,  the  roles  of  the  team  members  influence  the  design  of  the 

workflow  within  the  IEE.  The  following  team  members  and  their  respective  roles  have  been 
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developed  based  on  the  experience  captured  in  the  JIIFC  use  case  and  other  roles  that  are 

needed  to  support  the  activities  defined  above. 

Stakeholders:  The  stakeholders  develop  the  Concept  of  Operations  (CONOPS)  document. 
This  document  will  be  used  to  determine  project  requirements,  the  external  systems 
diagram  and  the  objectives  hierarchy.  Frequent  interface  between  the  project  team  and  the 
stakeholders  may  be  required  at  the  beginning  of  the  project  to  ensure  project  team 
interprets  stakeholder’s  needs  correctly. 

Change  Control  Board  (CCB):  The  role  of  the  change  control  board  is  to  assess  the  change 
requests  created  during  systems  analysis.  These  include  problem  reports,  derived 
requirements,  new  requirements,  functional  architecture  variants.  The  changes  agreed 
upon  by  the  change  control  board  will  be  submitted  to  the  requirements  analyst  for 
appropriate  action. 

Requirements  Analyst:  The  role  of  the  requirements  analyst  is  to  manage  the  requirements 
identified  throughout  the  project  definition  phase  into  the  requirements  database.  Other 
responsibilities  include  the  management  of  the  requirements  baseline  after  change  request 
submitted  by  the  change  control  board.  This  ensures  that  all  derived/changed 
requirements  are  forwarded  from  the  DOORS  database  to  the  central  repository  dataset 
within  Interchange 

Operational  Architecture  Modeler:  The  Operational  Architecture  Modeler  is  responsible  for 
capturing  operational  data  and  processes  and  developing  the  operational  architecture 
model  according  to  a  specified  architecture  framework.  The  key  activities  are  developing 
an  activity  model  and  partitioning  the  activities  into  the  various  roles  performed.  In 
system  engineering  terms  this  is  basically  developing  the  functional  baseline. 

System  Architecture  Modeler:  The  role  of  the  System  Architecture  Modeler  is  to  develop 
the  system  architecture  model  according  to  a  specified  framework.  The  key  activities  are 
to  define  the  physical  model,  defining  the  functions  performed  by  each  of  the  physical 
components,  and  mapping  of  the  activities  to  the  functions.  In  systems  engineering  terms 
this  is  the  development  of  the  allocated  baseline. 

Functional  Analyst:  The  Functional  Analyst  is  responsible  for  developing  the  functional 
model  (what  the  system  must  do,  that  is  the  system  functions  and  the  data  flows  between 
them).  In  the  final  analysis  the  functional  analyst  produces  the  operational  activities  and 
the  information  exchanges  among  them.  After  the  operational  activities  are  defined  the 
functional  analyst  defines  how  they  are  implemented  by  system  functions.  The  functional 
analyst  may  also  develop  executable  models  of  both  the  operational  activity  model  and 
system  functional  model.  The  role  of  the  functional  analyst  is  inherited  by  the 
Operational  Architecture  Modeler  and  System  architecture  Modeler. 

Human  Factor  Analyst:  The  role  of  the  Human  Factor  Analyst  is  to  decompose  the 
operational  activities  into  discrete  tasks  that  are  handled  by  human  operators  and  /  or 
computer  systems.  The  human  factor  analyst  shall  provide  performance  prediction  of  the 
human-in-the-loop,  which  can  affect  the  rewriting  of  requirement. 
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Model  Manager  (Interchange)  /  Analyst:  The  role  of  the  Model  Manager  /  Analyst  is  to 
manage  the  integrated  architecture  models  and  provide  configuration  support  and 
synchronization  between  the  models  in  the  central  repository  currently  support  by 
Interchange.  This  Analyst  ensures  that  the  models  are  consistent  as  they  are  being 
developed  and  integrated.  He/She  also  enforces  the  workflow  process  and  provides 
notification  to  appropriate  team  members  regarding  changes  in  the  databases  that  may 
impact  their  work. 

Communication  Network  Modeler:  The  role  of  the  Communication  Network  Modeler  is  to 
detail  the  network  engineering  requirements  (bandwidth,  latency,  performance).  The 
Network  Modeler  takes  the  physical  model  from  Interchange  (originally  developed  in 
CORE)  and  creates  the  network  topology  within  OPNET.  After  simulation  is  completed 
the  derived  requirements,  problem  reports  and  network  topology  elements  must  be  sent  to 
Interchange  where  they  are  incorporated  into  the  requirements  via  the  change  control 
process. 

3.4  Workflow  and  Dataflow  in  the  IEE 

Workflow  identifies  the  steps  and  interactions  between  team  members  to  execute  the  engineering 
activities,  and  dataflow  describes  the  sequence  and  content  of  data  exchange  between  tools.  Figure 
5  illustrates  the  interaction  among  the  engineering  team  members  and  their  activities.  The 
complete  description  of  the  workflow  is  an  elaborated  document  and  can  be  better  viewed  in  a 
web-based  UML  model  [9].  An  instance  of  the  workflow  is  provided  in  Section  3.5. 


DRDC  Ottawa  TM  2005-118 


11 


CapDEM  IEE  Process  Use  Case  Model 


Stakeholder 
(from  CapDEM  Actors) 


Develop  Operational  Needs 

(from  CapDEM  System  Use  Cases) 


■ 


«include>> 


yy 


Model 

Manageme... 

(from  CapDEM  Actors)  Define  Network  Performance 

«include» 

(from  CapDEM  System  Use  Casas) 


Manage  Requirements  Baseline 

(from  CapDEM  System  Usa  Cases) 


«include>> 


Manage  Models 


Network  Modeler 


(from  CapDEM  System  Use  Cases)  <<include>:>  (from  CapDEM  Actors) 


Requirements 
Analyst 

(from  CapDEM  Actors)  Develop  Originating  Requirements 

«include>> 

(from  CapDEM  System  Use  Cases)  / 


«include» 


Perform  ECP  functions 

(from  CapDEM  System  U9a  Casas) 


«lnclude>> 


CORE  System 
Architectu... 

(from  CapDEM  Actors) 


Cj 


Define  System  Model 

(from  CapDEM  System  Use  Cases) 


O 


Change  Control 
Board 

(from  CapDEM  Actors) 


Functional  CORE  Define  Operational  Model  Define  Human  Factor  Performance  Human  factor 

Analyst  Operation...  (from  CapDEM  System  Use  Cases)  (from  CapDEM  System  Use  Cases)  Analyst 

(from  CapDEM  Actors)  (from  CapDEM  Actors)  (from  CapDEM  Actors) 


Figure  5  The  Integrated  view  of  the  activities  and  team  members  supported  by  the  IEE 
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3.5  Live  Demonstration  of  the  IEE 


A  “live”  demonstration  of  the  CapDEM  IEE  was  performed  in  December  2004  at  the  Future 
Forces  Synthetic  Environments  (FFSE)/DRDC  Advanced  Collaborative  Capability 
Engineering  and  System  (ACCES)  Facility  in  Ottawa.  Understanding  that  normal  systems 
engineering  activities  usually  takes  days,  and  more  likely  weeks,  to  complete,  it  is  difficult  to 
demonstrate  the  actual  workflow  in  an  one  hour  demonstration.  However,  the  authors  believed 
that  the  audience  would  gain  a  better  appreciation  of  the  IEE  if  they  could  visualize  the 
engineering  workflow.  As  a  result,  the  CapDEM  team  decided  to  take  a  “cooking  show” 
approach  to  demonstrate  the  IEE.  The  “cooking  show”  approach  required  the  team  to  prepare 
several  sets  of  datasets  in  advance,  and  demonstrate  only  the  relevant  steps  of  the  workflow 
(e.g.  executing  the  plug-ins)  in  real  time. 

The  demonstration  showed  the  activities  in  the  IEE  following  the  workflow/dataflow  below. 
Figure  6  depicts  graphically  the  same  sequence  of  event.  The  numbers  noted  on  Figure  6 
correspond  to  the  numbers  listed  under  each  activity  below. 

Create  Requirements  database  in  DOORS 

1.  Create  the  originating  requirements  database  in  DOORS  by  creating  two  modules 
(A&B)  for  the  Statement  of  Operations  (SOR)  and  Concept  of  Operations 
(ConOps)  respectively. 

Upload  requirements  database  to  the  central  repository 

2.  Export  requirements  to  Interchange  (the  central  repository)  by  running  DOORS 
script  to  export  these  modules  in  CSV  (common  separated  value)  format. 

3.  Import  these  CSV  files  into  Interchange  (create  3  models  A,  B  and  X,  which  is  the 
union  of  A  and  B). 

Export  requirements  to  CORE-readable  format  (i.e.  rdt  file) 

4.  Create  new  model  C  in  Interchange.  Make  Model  C  the  default  container  and  add 
to  it  the  selected  requirements  to  be  to  export  to  CORE. 

5.  Set  up  a  change  notification  agent  in  Interchange  to  monitor  the  changes  to  these 
requirements. 

6.  Export  model  C  by  running  the  appropriate  export  command  in  Interchange.  This 
will  generate  a  rdt  file 

Importing  the  requirements  into  CORE  and  perform  functional  analysis 

7.  Import  the  rdt  file  generated  in  the  previous  step  into  Core. 

8.  The  architecture  team  develops  the  architecture  models  and  performs  functional 
analysis  to  determine  if  requirements  are  achievable  within  project  constraints. 
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9.  If  a  problem  is  discovered  with  an  originating  requirement,  an  issue  is  created  and 
linked  to  the  affected  requirement(s). 

Export  Issues  identified  in  functional  analysis  back  into  Interchange 

10.  Import  the  rdt  file  with  the  architecture  model  and  related  issues  generated  in  the 
previous  step  into  Model  C  in  Interchange.  The  changes  defined  in  the  rdt  file  are 
merged  into  the  existing  Model  C  in  Interchange. 

1 1 .  Change  notification  agents  will  be  triggered  if  there  are  issues  attached  to 
requirements  being  monitored  (e.g.  CCB  members  will  receive  email  notification). 

12.  CCB  accesses  Interchange  to  view  the  open  Problem  Reports  that  contain  issues 
identified  by  functional  analysts. 

Resolve  issues 

13.  Conduct  CCB  to  resolve  open  issues. 

14.  Update  DOORS  database  with  any  changes  required  as  a  result  of  the  CCB 
decision. 

Update  central  repository  after  CCB 

15.  Run  DOORS  export  script  to  generate  CSV  files  for  each  module. 

16.  Update  Model  X  in  Interchange  with  the  new  CSV  files  generated  from  DOORS. 

17.  Change  the  CORE  Export  attribute  of  Model  C  to  “incremental”. 

18.  Return  to  step  6  if  needed. 

Export  CORE  physical  connectivity  model  to  OPNET 

19.  Create  high  level  communication  model  in  CORE 

20.  Merge  the  changes  to  the  Core  model  into  Model  C  in  Interchange. 

21.  Create  new  Model  D  in  Interchange.  Make  Model  D  the  default  container  and  add 
to  it  the  objects  to  be  to  exported  to  OPNET. 

22.  Export  the  Model  D  as  an  XML  file  to  OPNET 

23.  Perform  Network  Analysis  in  OPNET 

Import  OPNET  model  into  central  repository 

24.  Report  Network  related  issues  and  create  XML  export  file 

25.  Update  Model  D  in  Interchange  with  the  OPNET  XML  file. 
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Figure  6  Engineering  Workflow  used  in  the  Live  Demonstration 
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4.  Two  Basic  Requirements  for  an  Effective  (EE 


Based  on  the  experience  gained  from  this  implementation,  two  basic  requirements  for  an 
effective  IEE  became  evident.  First,  the  need  for  a  strong  engineering  data  management 
scheme  for  the  project  team,  and  second,  the  ability  to  enable  project  level  situation 
awareness. 

4.1  Engineering  Data  Management 

To  allow  a  distributed  project  team  to  be  productive,  it  is  essential  to  provide,  at  minimum, 
the  following  data  management  functions  in  an  integrated  manner: 

•  Ability  to  control  data  access  to  ensure  data  integrity 

•  Ability  to  configuration  manage  data 

•  Ability  to  integrate  engineering  data  and  models  to  facilitate  content  validation 

A  common  approach  to  project  data  management  is  using  a  shared  folder  as  a  central  data 
repository  where  most  team  members  can  deposit  and  retrieve  project  related  information. 
Some  of  the  problems  related  to  using  only  a  shared  folder  for  data  management  include: 

•  Difficulties  in  identifying  the  appropriate  version  or  approved  baseline  of 
engineering  /  architecture  products 

•  Difficulties  in  finding  files  because  they  could  be  easily  misplaced  or 
overwritten 

•  No  integrated  data  management,  have  to  rely  on  individuals  to  maintain  their 
data. 

•  Lack  of  common  approach  to  maintain  history  of  product  development. 

•  Data  cannot  be  reused  readily 

•  Not  possible  to  integrate  and  validate  data  /  engineering  models 

Although  some  of  these  problems  can  be  resolved  by  enforcing  a  manual  process  to  maintain 
the  central  repository,  it  is  an  unnecessary  burden  on  the  team  members,  and  often  becomes  a 
source  of  frustration  when  data  is  mishandled. 

4.2  Situation  Awareness 

Besides  being  able  to  focus  on  their  own  engineering  tasks,  team  members  must  develop  a 
sense  of  awareness  of  the  on-going  situation  of  the  project,  and  understand  how  their  work 
contribute  to  its  progress.  This  is  particularly  important  for  a  geographically  distributed 
project  team  where  frequent  face-to-face  interaction  may  not  be  possible. 

One  way  to  improve  situation  awareness  is  to  provide  an  environment  that  enhances 
interaction.  The  parameters  describing  the  nature  of  collaboration  can  be  found  in  reference 
[11].  The  nature  of  collaboration  can  be  described  by  the  degree  of  reach ,  richness  and  quality 
of  information.  Figure  7  provides  a  graphical  summary  of  these  parameters. 
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Figure  7  Parameters  describing  the  Nature  of  Collaboration 


A  combination  of  a  data  repository,  telephone  conversations,  emails,  video  conferencing  and 
face-to-face  meetings  are  commonly  used  to  keep  team  members  informed  on  project  status, 
issues  and  solutions.  Many  people  are  familiar  with  the  limitations  of  using  these  approaches 
for  communication.  Telephone  tags,  flooded  email  boxes,  mountains  of  duplicated  documents, 
lost  data  due  to  technical  or  human  errors,  information  captured  in  various  forms  that  cannot 
be  searched  easily  are  just  some  examples  of  issues  project  teams  have  to  deal  with. 

4.3  IEE  Functions  Supporting  Collaboration 

The  IEE  is  not  a  panacea,  but  it  does  offer  functions  that  facilitate  distributed  teamwork.  It 
provides  strong  support  on  integrated  engineering  data  management,  allowing  Individual 
members  to  focus  on  performing  their  engineering  tasks  rather  than  worrying  about  data 
maintenance  and  synchronization.  Many  of  the  IEE  functions  also  enhance  the  nature  of 
collaboration  described  in  Figure  7. 

The  Interchange  SE  repository  provides  the  data  management  functions  of  the  IEE.  Together 
with  a  set  of  plug-ins  that  enable  effective  data  flow  between  domain  engineering  tools  to  the 
central  repository,  and  a  well-defined  workflow  process,  much  of  the  project  level  data 
management  routines  will  be  carried  out  on  the  central  repository  by  a  database  administrator. 

IEE  data  management  functions  include: 
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•  A  common  repository  and  data  schema  to  store  all  architecture  data,  trade 
study  analyses  and  project  related  documents 

•  Integrate  data  /  model  within  the  repository 

•  Provide  integrated  views  of  engineering  data  /  models  generated  by  various 
team  members. 

•  Automatic  version  control  and  selective  baselining  of  data  and  models  to 
enforce  data  consistency  and  enable  synchronization  of  activities 

•  Access  control  by  user  profile 

•  Efficient  data  flow  between  domain-specific  tools  to  facilitate  data  exchange 
and  reuse. 

•  Automatic  change  notification  to  subscribers  on  selected  data  elements 

•  Automatic  generation  of  reports  on  subscribed  contents 


To  enhance  project  situation  awareness,  the  IEE  offers  the  following  functions  to  improve 
collaboration. 

Reach: 

•  Asynchronous  (space  and  time):  IEE  is  accessible  through  various  computer 
networks  so  project  information  is  reachable  by  authorized  team  members  on 
demand. 

•  Selective:  user  profiles  determine  data  access.  In  addition,  agent  services  (e.g. 
change  notification  agent)  are  provided  based  on  subscription.  These  two 
features  provide  selectivity  on  both  the  users  and  the  data. 

•  Simultaneous:  multi-user  concurrent  access  to  the  database  is  supported 
through  web-interface  or  Interchange  clients. 

Richness: 

•  Multi-media  support:  User  can  attached  and  view  any  media  file  in  any 
format  to  the  central  repository  as  long  as  the  application  software  (or  a  viewer 
software)  is  accessible  from  the  Interchange  Server. 

•  Tools:  The  use  of  plug-ins  allows  data  flow  between  the  central  repository  and 
specialized  engineering  tools. 

Quality  of  Interaction:  The  current  IEE  is  not  designed  to  support  multi-user 

interaction. 

Although  the  IEE  is  not  intended  to  support  real-time  multiple  user  interaction,  the 
combination  of  tools  and  technologies  in  the  overall  CEE  will  supplement  this  deficiency  in 
the  IEE. 
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5.  Concluding  Remarks 


This  IEE  implementation  has  been  a  worthwhile  exercise  because  it  has  generated  valuable 
first-hand  experience  for  the  CapDEM  team  to  understand  the  process  involved  in,  and  the 
requirements  for,  building  an  effective  IEE.  The  results  are  captured  in  Section  3  and  4, 
respectively.  To  reiterate,  the  implementation  process,  as  derived  from  the  lessons  learned, 
involves  the  following  steps: 

•  Identify  the  application  this  environment  will  support 

•  Describe  the  engineering  activities  and  engineering  products  to  be  generated 

•  Determine  team  composition  and  the  computing  environment  (tools  and 
network  connectivity) 

•  Define  workflow  and  dataflow  within  the  IEE 

•  Develop/  modify  /  fine-tune  the  plug-ins  that  link  tools  to  a  central  repository 

The  two  basic  requirements  that  contribute  to  an  effective  IEE  are: 

•  Integrated  engineering  data  management  and  efficient  data  exchange  that 
enable  team  members  to  focus  on  their  domain-specific  tasks  rather  than 
worrying  about  data  maintenance  such  as  back  ups,  configuration 
management,  and  data  integration. 

•  Effective  way  for  team  members  to  acquire  project  situation  awareness  that 
allows  team  members  to  work  independently  yet  maintain  enough  awareness 
of  the  progress  in  the  project  to  maintain  self-synchronization. 


The  major  challenges  encountered  and  lessons  learned  from  this  exercise  have  been  captured 
in  [1];  therefore,  they  will  not  be  repeated  in  this  report 

Two  future  activities  have  been  planned  to  utilize  the  existing  IEE.  First,  the  IEE  will  be  used 
to  provide  engineering  data  management  for  the  CapDEM  Concept  Development  and 
Experimentation  (CD&E)  exercise.  This  CD&E  exercise  will  employ  the  same  set  of  tools  to 
demonstrate  the  application  of  capability  engineering  concepts  to  support  CD&E. 

Second,  the  IEE  will  be  used  to  develop  a  Synthetic  Environment  Development  Environment 
(SEDE).  The  purpose  of  the  SEDE  is  to  provide  a  facility  that  will  assist  the  different  types  of 
Synthetic  Environment  (SE)  users  i.e.  stakeholders  who  identify  the  problem  to  be  addressed, 
engineers  and  specialists  who  provide  engineering  solutions,  and  SE  implementers,  so  that  SE 
can  be  delivered  faster,  better  and  cheaper..  These  two  activities  will  be  carried  out  in  FY 
05/06  under  the  CapDEM  TDP. 
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List  of 

symbols/abbreviations/acronyms/initialisms 


CapDEM 

Collaborative  Capability  Definition,  Engineering  and  Management 

CEE 

Collaborative  Engineering  Envrionment 

CONOPS 

Concept  of  Operation 

COTS 

Commercial  Off  TheShelf 

DRDC 

Defence  Research  and  Development  Canada 

DSE 

Decision  Support  Environment 

ECP 

Enterprise  Change  Proposal 

HLA 

High  Level  Architecture 

IDMA 

Interoperability  Data  Management  and  Analysis  Environment 

IEE 

Integrated  Engineering  Environment 

IPME 

Integrated  Performance  Modeling  Environment 

JSA 

Joint  Systems  Analysis 

JSORT 

Joint  Staff  Operational  Research  Team 

M&S 

Modeling  and  Simulation 

NCEE 

Naval  Collaborative  Engineering  Environment 

SE 

Synthetic  Environments 

T&E 

Test  and  Evaluation 

TDP 

Technology  Demonstration  Projects 

TTCP 

The  Technical  Cooperative  Panel 

UML 

Unified  Modeling  Language 
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